1. Field of the Invention
The present invention relates to a method for isolating minimal distinguishing stimuli in design verification and software development.
2. Background Art
a. Computers and Software
A computer has a central “brain” called a processor that controls what the computer is going to do. The processor does this by doing a series of tasks or operations, and doing them very quickly. The thing that determines which tasks or operations a processor is going to do is called a program.
A program is a long list of instructions that tell the processor what to do. The processor typically gets one instruction at a time, performs some operation based on the instruction, and then moves to another instruction, and so on. The processor does not necessarily perform the instructions of a program in order. Instead, the processor can jump around. It may execute two or three instructions in a row, then based on the results of those instructions, jump back, skip ahead, or continue in sequence. The processor may even begin executing another program before it has completed the first, or it may decide to stop altogether.
Like books, computer programs must be written. The person who writes programs is called a programmer, or software developer.
b. Software Development
Software development is the writing of a computer program. Software development typically proceeds in several stages. The first step is that the software is written. This is a substantial effort, as many computer programs contain hundreds of thousands of lines. (A program is typically written in what is called a software code or language, so a program is often said to have so many lines of “code”). After a program is written it must then be tested. If there is something wrong with the software it must then be fixed. Once the software is fixed, the development process is complete and the program is ready to use.
The testing and fixing of software is an important part of the software development process and can be very time consuming. An error in a program is called a “bug” and the process of finding and removing software bugs is called “debugging”.
c. Debugging Software
One way of debugging software is to determine if the program fails when the program is used. This process may be automated—a separate program often called a test case or test program is used to test the software being developed. The test program is such that if the program works correctly, some predicted results will occur. During testing, every line of code in the program is tested. A bug is found when the actual results of the test differ from the predicted results. The bug can involve improperly managed data, abnormal program termination, or even an operating system crash.
Once a bug is found, the developer tries to fix the bug by rewriting the code in the area where the bug occurred. After the code is rewritten, the programmer would like to be able to re-test the program to determine if the fix was successful. This means that the programmer wants to be able to reproduce the condition (called an error condition) that revealed the bug in the first place. If the error condition can't be reproduced, you can't be sure if you really fixed the bug. In this sense, debugging software is like trying to repair a car that is “making a funny noise”. If the car makes the noise when you drive, but does not make the noise when the mechanic looks at the car, the mechanic can't figure out what is wrong with the car. A driver needs to be able to make the car make the noise so the mechanic can fix it. Then, after the car is fixed, the driver wants to do the same things that in the past made the noise to see if the repair was successful.
Like the driver, the programmer needs to be able to reproduce the error condition at will so that the bug can be fixed. If the programmer cannot reproduce the error condition, he cannot be certain with a high probability that the bug has been fixed.
A problem in debugging is that the programmer must retrace too many steps in the process so as to recreate the error condition. Consider when the developer runs the test case and after several minutes, an error condition occurs. This may be after several hundred thousand lines of code have been executed. In order to recreate the error condition, the programmer may be forced to rerun the entire test to the exact place and time to duplicate the error. This process wastes valuable time and money. Currently the prior art has not provided a good way to easily and automatically recreate an error condition in tested software.